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(54) Method and Apparatus for route optimisation in nested mobile networks 


(57) A method of transmitting at least one data pack- 
et from a communication node in a data communication 
network. The method includes receiving a request at a 
communication node, to transmit at least one data pack- 
et to a first destination address and searching for the 
first destination address in a cache of the communica- 
tion node. A determination of an intermediary address 
of the destination address is made. The destination ad- 
dress then is replaced with the intermediary address 
and the steps of searching, determining and replacing 


are repeated, until no new intermediary address is 
found. The at least one data packet is then transmit to 
the destination address via the identified intermediary 
address(es). 

A communication unit (corresponding node) com- 
munication message and method for building a linked 
binding cache are also described. 

In this manner, an optimised data path is deter- 
mined in order to send at least one data packet to an 
intended recipient, for example in a nested mobile net- 
work scenario. 
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Description 

Field of the Invention 

[0001] This invention relates to telecommunication 
systems in which data flows between mobile nodes, for 
example personal digital assistants with wireless com- 
munication capability, and a data network, for example 
the Internet. 

Background of the Invention 

[0002] The Internet is becoming more and more pop- 
ular, and users increasingly wish to access the Internet 
whilst on the move. Different types of mobile nodes (i. 
e. mobile communication units) may be employed for 
this purpose, for example a mobile telephone or a per- 
sonal digital assistant (PDA) with wireless communica- 
tion capability. 

[0003] Increasingly, mobile users are accessing the 
Internet via different types of fixed or wireless access 
networks, for example a cellular radio communication 
network, such as a Universal Mobile Telecommunica- 
tion System (UMTS) network, a HiperLAN/2 or IEEE 
802.11b local area network, a Bluetooth local commu- 
nication system, orfixed accesses such as the Ethernet, 
and so on. The data route between the mobile node and 
the Internet further comprises an Internet protocol sub- 
net (IP subnet), such that the route is as follows: mobile 
node - access network - IP subnet - Internet (and re- 
verse order for the data route from the Internet to the 
mobile node). 

[0004] It is currently possible to seamlessly handover 
accessing of the Internet from one access network to 
another, for example by using a protocol known as Mo- 
bile-IP. 

[0005] Traditional mobility support aims to provide 
continuous Internet connectivity to mobile hosts, there- 
by allowing individual mobile users to connect to the In- 
ternet whilst being mobile and moving their Internet ac- 
cess location. In contrast, network mobility support is 
concerned with situations where an entire network 
changes its point of attachment to the Internet topology 
and thus its accessibility in the topology. Such a network 
in movement can be called a Mobile Network. 
[0006] There exist a large number of scenarios where 
such Mobile Networks exist. For example, a Personal 
Area Network (PAN, i.e. a network of several personal 
devices attached to an individual) is known whereby the 
PAN changes its point of attachment to the Internet to- 
pology whilst the user is walking in a shopping mall. In 
addition, a-network may be embedded in a bus or air- 
craft, providing on-board Internet access to passengers. 
A passenger may use a single communication device 
(e.g. a laptop) or be itself a Mobile Network (e.g. a PAN). 
Notably, this configuration illustrates a case of a Mobile 
Network visiting a Mobile Network (i.e. nested mobility). 
[0007] As such, a Mobile Network can be defined as 
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a set of nodes composed of one or more IP-subnets at- 
tached to a Mobile Router (MR). These IP subnets may 
also be viewed as a mobile unit, with respect to the rest 
of the Internet, i.e. a MR and all its attached nodes (so 
5 called Mobile Network Nodes or MNNs). 

[0008] A document authored by Thierry Ernst, Hong- 
Yon Lach, IETF Internet-Draft draft-ernst-mo net-term i- 
nology-00.txt, February 2002, describes a list of defini- 
tions for the Mobile Network terminology that can be ap- 
10 plied in this application. In particular, the following terms 
may be defined as follows: 

(i) A Local Fixed Node (LFN): 
A node permanently located within the Mobile Net- 
work and that does not change its point of attach- 
ment. A LFN can either be a Local Fixed Host (LFH) 
or a Local Fixed Router (LFR). 

(ii) A Local Mobile Node (LMN): 
A local mobile node is one that belongs to the Mo- 
bile Network and changes its point of attachment 
from a link within the Mobile Network to another link 
within or outside the Mobile Network. In this regard, 
it can be assumed that the home link of the LMN is 
a link within the Mobile Network. A LMN can either 
be a Local Mobile Host (LMH) or a Local Mobile 
Router (LMR). 

(iii) A Visiting Mobile Node (VMN): 
A VMN is one that does not belong to the Mobile 
Network, and changes its point of attachment from 
a link outside the Mobile Network to a link within the 
Mobile Network (i.e. the home link of the VMN is not 
a link within the Mobile Network). A VMN that at- 
taches to a link within the Mobile Network obtains 
an address on that link. A VMN can either be a Vis- 
iting Mobile Host (VMH) or a Visiting Mobile Router 
(VMR). 

(iv) A Mobile Network Prefix: 
A bit string that consists of a number of initial bits of 
an IP address, which identifies a Mobile Network 
within the Internet topology. Nodes belonging to the 
Mobile Network (i.e. at least MR, LFNs and LMNs) 
share the same IPv6 "network identifier". For a sin- 
gle mobile IP-subnet, the Mobile Network Prefix is 
the "network identifier" of this subnet. 

(v) An Egress Interface of a MR: 
This is the interface attached to the home link if the 
Mobile Network is at home. Alternatively, it is the 
interface attached to a foreign link if the Mobile Net- 
work is in a foreign network. 

(vi) An Ingress Interface of a MR: 
This is the interface attached to a link inside the Mo- 
bile Network. This interface is configured with the 
Mobile Network Prefix. 

(vii) AMR may have multiple Egresses and Ingress 
interfaces. 

[0009] Recently, there has been a lot of interest and 
research into the Mobile IPv6 specification, as de- 
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scribed in the document authored by David B. Johnson: 
IETF Internet-Draft draft-ietf-mobileip-ipv6-15.txt, July 

2001. A major concern with Mobile Ipv6 is that the re- 
search has proven that the IPv6 standard is currently 
unable to adequately address network mobility. In par- 
ticular, the document authored by Thierry Ernst and 
Hong-Yon Lach: IETF internet-Draft draft-ernst-mo- 
bileip-v6-network-02.txt, June 2001, details problems 
encountered with Mobile-IPv6 in supporting Mobile Net- 
works. 

[0010] In summary, it has been determined that even 
if a MR's Home Agent (HA) is able to intercept packets 
addressed to MNNs that are operating behind the MR, 
the MR's HA is clearly unable to encapsulate them to 
the care-of-address of the appropriate MR. Note that 
every data packet has a source address and a destina- 
tion address. A tunnelled packet is a packet that encap- 
sulates in it another packet. Thus, the encapsulating 
packet has a pair of source and destination addresses. 
A further encapsulated packet has additional source 
and destination addresses. 

[0011] The lack of knowledge of a true location of a 
particular MNN results from the HA not knowing any 
(never mind a preferred) data route to the Mobile Net- 
work, once it has moved to a Visited' location. Unfortu- 
nately, when a MR registers with its HA the MR only in- 
forms the HA to record a host-specific route in its routing 
table. The inventors of the present invention have rec- 
ognised that a preferred network route generated using 
the mobile network address (prefix, prefix length and 
care-of-address) of the appropriate MR would greatly 
assist in this matter. 

[0012] In the field of this invention, the Mobile IPv4 
specification, detailed in C. Perkins, IETF RFC3220, "IP 
Mobility Support for IPv4 n , Standards Track, January 

2002, describes how Network Mobility can be supported 
in the case of IPv4 mobility. However, it has also been 
determined that IPv4 does not support route optimisa- 
tion for MNNs behind the MR. Thus, all the (incoming 
and outgoing) traffic between a MNN and its corre- 
sponding nodes (CNs) is passed to the MR's Home 
Agent. This problem is exacerbated in the case of nest- 
ed mobility, which is where a CN wishes to pass data to 
a MNN that is behind a number of MR links, or a mobile 
node visiting a mobile network. In the case of nested 
mobility, the packet will thus be encapsulated several 
times as a result of being routed through all of the Home 
Agents of all the nested MRs. This is clearly inefficient 
routing. 

[0013] A solution to this routing problem is presented 
in the document authored by T J. Kniveton: IETF Inter- 
net-Draft draft-kniveton-mobrtr-00.txt, November 2001 , 
where provision of a means to support mobile networks 
with nomodificationsXo Mobile IP (v4 or v6) is described. 
The mechanism proposed to address the problem of 
nested mobility is described with respect to FIG. 2. 
When a MR, for example MR2 260, has attached to a 
visited network 110 (via another Mobile Network MR1 


link), a bidirectional tunnel 21 0, 215, 220 is established 
between MR2 260 and its HA - HA2 250. When a node, 
for example LFN2 165, is attached to MR2 260 and 
wishes to send an IP packet to a CN, say CN2 255, via 
5 the Internet 115, that packet is tunnelled by MR2 260 (to 
HA2 250) and again by MR1 150 (to HA1 240). The mul- 
tiple-tunnelled data packet is then passed to the HA of 
the latest MR to tunnel the data, namely to HA1 240. 
HA1 240 then forwards it to the intended recipient CN2 
255 via the source MR's HA, namely HA2 250. 
[0014] This proposed data routing method, and the 
problems associated with it, are best described by way 
of an example. Thus, let us assume that LFN2 165 
sends a data packet to CN2 255. The data packet is first 
routed 205 towards MR2 260. The data packet is then 
tunnelled by MR2 260 to be sent to HA2 250. This tun- 
nelling process of the data packet from MR2 260 to HA2 
250 is itself, by necessity, first routed 210 towards its 
linked MR, namely MR1 150. MR1 150 further tunnels 
the data and forwards 21 5 the multiple-tunnelled packet 
to its HA, namely HA1 240. HA1 240 de-tunnels the data 
packet, as tunnelled by MR1 150 and forwards 220 the 
partially de-tunnelled packet to its original intended re- 
cipient, HA2 250. HA2 250 further de-tunnels the pack- 
et, as tunnelled by M R2 260, and forwards 225 the whol- 
ly de-tunnelled data packet to CN2 255. 
[0015] Clearly, the solution proposed does not pro- 
vide any support for route optimisation, since both in- 
bound and outbound packets are routed through the 
Home Agent of both MRs 1 50, 260. In fact, packets from 
CN2 255 addressed to LFN2 165 will follow the same 
path (in reverse order) and will then be encapsulated by 
each Home Agent 240, 250 of each of the nested MRs 
150, 260. Once again, this is clearly inefficient routing, 
particularly for a practical situation whereby there may 
be many more than two levels in the nested network. 
[0016] The solution presented in a document au- 
thored by Thierry Ernst and Hong-Yon Lach: IETF Inter- 
net-Draft draft-ernst-mobileip-v6-network-02.txt, June 
2001 , proposes a means forsupporting network mobility 
in the framework of Mobile IPv6. This solution introduc- 
es the following concept: when a Mobile Router roams 
to a visited network, it sends a Prefix Scope Binding Up- 
date to its Home Agent (HA). Unlike a classical Mobile 
IPv6 Binding Update message, a Prefix Scope Binding 
Update does not bind a home address with a care-of 
address. 

[0017] In contrast, the MR Prefix is bound with the MR 
care-of address, for a particular MR. Upon reception of 
a packet whose prefix matches with the MR prefix, the 
Home Agent must then tunnel the packet to the MR 
care-of-address that has been identified as being able 
to deliver the tunnelled packet to the intended recipient. 
Likewise, a MR may send prefix-scope BUs to the cor- 
responding nodes of the nodes it serves. This solution 
brings a more efficient support of mobile networks to 
Mobile IPv6, since it may provide a limited improvement 
to route optimisation. 
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[0018] However, the scope of this draft has explicitly 
excluded the case of nested mobility, which presents a 
significant hurdle to efficient route optimisation. As such, 
the solution proposed in the Thierry Ernst document, 
IETF Internet-Draft draft-ernst-mobileip-v6-network- 
02.txt, June 2001, fails to provide a useful solution to 
route optimisation in many practical situations. Again, 
the problems that emanate from this document, partic- 
ularly in the case of nested mobility, are best highlighted 
in an example situation. 

[0019] Referring now to FIG. 3, a mechanism for rout- 
ing data packets in an IPv6 network using the proposal 
of Thierry Ernst: IETF Internet-Draft draft-ernst-mo- 
bileip-v6-network-02.txt, June 2001 . Notably, the prob- 
lems emanating from using this mechanism in a nested 
mobility are highlighted. 

[0020] A mobile router MR1 150 is attached to a vis- 
ited link 110. A mobile router MR2 260 is attached to 
MR1 's link 1 55. A local fixed node LFN2 1 65 Is attached 
to MR2's link 230. Again, let us assume that LFN2 1 65 
is attempting to communicate with a corresponding 
node CN2 255. 

[0021] Let us further assume that, at the beginning of 
the simple scenario detailed in FIG. 3, MR1 150 and 
MR2 260 have already sent BU messages to their re- 
spective HAs 240, 250. That is, HA1 240 knows that 
M R Vs 1 50 prefix is reachable at M R1 's care-of address. 
Similarly, HA2 250 knows that MR2's 260 prefix is reach- 
able at MR2's care-of address. 

[0022] When a data packet is sent from CN2 255 to 
LFN2 165, CN2 255 has no knowledge about LFN2's 
1 65 actual location. Thus, the data packet that it sends 
is therefore routed 325 towards home link-2 1 05. HA2 
250 intercepts the data packet and tunnels it to MR2's 
care-of address. This can be understood as HA2 250 
knows that MR2's prefix is reachable at MR2*s care-of 
address. 

[0023] This tunnelled packet (from HA2 250 to MR2's 
260 care-of address) is routed 320 toward link-1 245, 
since MR2's 260 care-of address matches MR1's 150 
prefix. HA1 240 intercepts the data packet and tunnels 
it to MR1 's care-of address, namely towards the visited 
link 110, since HA1 240 knows that MR1's prefix is 
reachable at MR1's care-of address. 
[0024] MR1 150 then de-tunnels the data packet re- 
ceived from HA1 240. MR1 150 then forwards the con- 
tent to the original recipient, MR2 260. Meanwhile, MR1 
1 50 sends a Binding Update to the sender of the encap- 
sulated packet (that is HA2 250) to inform it that MR1's 
prefix is reachable at MR1's care-of address. Note that 
from MRVs point of view, HA2 250 is a Correspondent 
Node and not its Home Agent (i.e. the 'H' bit in the BU 
is not set). It is up to the HA2 250 to accept this Binding 
Update or not. 

[0025] MR2 260 de-tunnels the data packet that it re- 
ceived (i.e. the portion of the data packet that had been 
encapsulated by HA2 250) and forwards the content 
(the initial packet from CN2 255) to LFN2 165. Mean- 


while, M R2 260 sends a Binding Update message to the 
sender of the encapsulated packet (that is, CN2 255) to 
inform it that MR2's prefix (covering the LFN2 165 ad- 
dress) is reachable at MR2's care-of address. This in- 

5 formation is stored in the CN's binding cache 370. 
[0026] Once an initial packet has reached its destina- 
tion, transmission of a second or subsequent packet 
from CN2 255 to LFN2 1 65 leads to the scenario depict- 
ed in FIG. 4. After having reviewed its binding cache 

10 370, CN2 255 recognises that LFN2 1 65 is reachable at 
MR2's care-of address. Thus, it sends the data packet 
to MR2's care-of -address with a routing header for LFN2 
165. MR2's care-of-address belongs to MRVs link and 
is therefore routed towards Home Link-1 245. In this 

is manner, a minor improvement to route optimisation is 
achieved by the bypassing of the transmission of the da- 
ta packet to, and from, HA2 250. 
[0027] HA1 240 then intercepts the data packet and 
tunnels the packet to MR1 's care-of address, since HA1 

20 240 knows that MR1 's prefix is reachable at M R1 's care- 
of address. 

[0028] MR1 1 50 de-tunnels the packet from HA1 240 
and forwards the content to the mobile router MR2 260 
of the originally intended recipient, LFN2 1 65. Mean- 
25 while, MR1 150 sends a Binding Update to the sender 
of the encapsulated packet (that is, CN2 255) to inform 
it that MR1' sprefix is reachable at MRVs care-of ad- 
dress. 

[0029] When receiving the original packet as sent by 

30 CN2 255, MR2 260 replaces its address in the destina- 
tion field of the packet with the address contained in the 
routing header (that is, LFN2 1 65) and forwards the data 
packet to the ultimate recipient. 
[0030] The inventors of the present invention have 

35 identified a significant problem with the scenario depict- 
ed in FIG. 4. All subsequent packets from CN2 255 to 
LFN2 1 65 will be routed in exactly the same manner as 
the second data packet. That is, there will be no subse- 
quent improvement towards route optimisation. This is 

40 more clearly shown in respect of FIG. 5. 

[0031] Referring now to FIG. 5, a known binding 
cache 500 is illustrated. The binding cache comprises 
a list of entries, specific to each MR in a nested mobility 
scenario. The binding cache entries include, for exam- 

45 pie a MR3 prefix and prefix length 530, with a link 532 
to a determined MR3 care-of-address 534, if one has 
been determined. The MR3 entry 535 is linked 536 to 
the next entry in the binding cache, namely that for MR2. 
The MR2 prefix and prefix length 520, includes a link 

50 522 to a determined MR2 care-of-address 524, if one 
has been determined. A similar arrangement and link 
526 is performed to-M R1 , and so on. 
[0032] In addition, the binding cache entries include 
a flag entry (not shown). A 'P' flag is the "Prefix Scope 

55 Registration" flag. When it is set, a "Home Address" field 
is filled with the Mobile Network prefix (the prefix that is 
advertised by the Mobile Router) and the" Prefix Length" 
corresponds to the length of the Mobile Network prefix. 


4 


7 


EP 1 367 780 A1 


8 


[0033] It is specified in the document by Thierry Ernst: 
IETF Internet-Draft draft-ernst-mobileip-v6-network- 
02.txt, June 2001, that the Binding Cache is searched 
for an entry corresponding to the destination address of 
the packet in one pass. As a result of the search, either 
nothing has been found (no entry), or the full address 
has been found (128-bit match for an IPv6 address, P 
flag unset), or the first bits of the destination address 
match with a registered prefix for the registered prefix 
length. In the latter case, the destination is located in a 
mobile network. 

[0034] Therefore, with reference to FIG . 4, when CN2 
255 has to send a packet to LFN2 165, CN2 255 still 
reviews its binding cache and finds the entry 'MR2 260 
prefix reachable at MR2 260 Co@' 520, 524. CN2 255 
does not even consider the entry 'MR1 150 prefix reach- 
able at MR1 Co© 1 510, 514, as this would appear to 
have no bearing on the LFN2 address. The inventors 
have recognised that this deficiency results from the 
LFN2 165 address being unrelated to the MR1 prefix. 
The fact that MR2 260 Co@ belongs to MR1 prefix is 
neither seen, nor even used by CN2 255. 
[0035] Consequently, the only optimisation that the 
Thierry Ernst proposal can support is related to the HA 
(HA2 250) of the MR (MR2 260) serving the communi- 
cating MNN (LFN2 165 in the above example). This so- 
lution describes indeed a means for having packets be 
sent directly from CN2 255 to HA1 240, instead of CN2 
255 to HA2 250 and thereafter to HA1 240. However, if 
there were n successive levels of nested mobility, this 
solution provides minimal route optimisation, no more 
than having a CN2 255 -> HA n _ 1 -> HA^ -»...-» HA1 
path instead of CN2 255 -> HA n -> HA^i -> HA^ -> ... 
-> HA1 path. This proposal is therefore still clearly inef- 
ficient, particularly in the case of nested networks. 
[0036] A need therefore arises for a mechanism, ap- 
paratus and associated methods to support route opti- 
misation in Network mobility, especially in the case of 
IPv6. In particular, a need has arisen to support route 
optimisation in the case of nested mobility, wherein the 
aforementioned problems are substantially alleviated. 

Statement of Invention 

[0037] In accordance with a first aspect of the present 
invention, there is provided a method of transmitting at 
least one data packet from a communication node in a 
data communication network, as claimed in Claim 1 . 
[0038] In accordance with a second aspect of the 
present invention, there is provided a method of gener- 
ating a routing header, as claimed in Claim 11 . 
[0039] I n accordance with a th i rd aspect of the present 
invention, there is provided a communication message, 
as claimed in Claim 15. 

[0040] In accordance with a fourth aspect of the 
present invention, there is provided a communication 
message, as claimed in claim 1 6. 
[0041] In accordance with a fifth aspect of the present 


invention, there is provided a communication unit, as 
claimed in Claim 1 8. 

[0042] In accordance with a sixth aspect of the 
present invention, there is provided a communication 

5 unit, as claimed in claim 20. 

[0043] In accordance with a seventh aspect of the 
present invention, there is provided a method for build- 
ing a linked binding cache, as claimed in claim 21 . 
[0044] In accordance with a eighth aspect of the 

10 present invention, there is provided a storage medium 
storing processor-implementable instructions, as 
claimed in Claim 27. 

[0045] In accordance with a ninth aspect of the 
present invention, there is provided an apparatus, as 
is claimed in Claim 28. 

[0046] In accordance with a tenth aspect of the 
present invention, there is provided a communication 
unit, as claimed in Claim 29. 

[0047] In accordance with a eleventh aspect of the 
20 present invention, there is provided a communication 
system, as claimed in Claim 30. 
[0048] Further aspects of the present invention are as 
claimed in the dependent Claims. 


[0049] 

FIG. 1 illustrates the movement of a Mobile Network 
30 in an Internet; 

FIG. 2 illustrates a known packet data routing mech- 
anism for mobile networks when applied to nested 
mobility; 

35 

FIG. 3 illustrates a known packet data routing mech- 
anism for mobile networks when applied to nested 
mobility that highlights the inefficiency of the data 
routing; 

40 

FIG. 4 illustrates a known packet data routing mech- 
anism for mobile networks when applied to nested 
mobility that highlights the inefficiency of an im- 
proved process of the data routing; and 

45 

FIG. 5 illustrates a known binding cache for routing 
data packets in mobile node networks. 

[0050] Exemplary embodiments of the present inven- 
so tion will now be described, with reference to the accom- 
panying drawings, in which: 

FIG. 6 illustrates a packet data routing mechanism 
for mobile networks when applied to nested mobility 
55 jn accordance with the preferred embodiment of the 
present invention; 

FIG. 7 illustrates a simple linked binding cache con- 


25 Brief Description of the Drawings 
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figuration in accordance with the preferred embod- 
iment of the present invention; 

FIG. 8 illustrates a generic linked binding cache 
configuration in accordance with the preferred em- 
bodiment of the present invention; 

FIG. 9 illustrates a flowchart of a process of access- 
ing address information from a linked binding cache 
in accordance with the preferred embodiment of the 
present invention; and 

FIG. 10 illustrates a flowchart of a method to build 
a linked binding cache in accordance with the pre- 
ferred embodiment of the present invention. 

FIG. 11 illustrates preferred examples of routing 
headers, generated in accordance with embodi- 
ments of the present invention. 

Description of Preferred Embodiments 

[0051] There is currently no standard mechanism to 
support Network mobility adequately, particularly in the 
case of IPv6 for nested mobility data networks. In par- 
ticular, there is no provision or support for route optimi- 
sation. This is a major issue, as nested mobility is a very 
realistic scenario for Mobile Router applications. In ad- 
dition route optimisation is much more important with re- 
gard to movement of a Mobile Network, than for move- 
ment of a single Mobile Node, since the amount of traffic 
handled is much greater. 

[0052] The preferred embodiment of the present in- 
vention is described with respect to route optimisation 
in transmitting at least one data packet between a cor- 
responding node (communication unit) and a local fixed 
node (or vice versa). It is envisaged that the correspond- 
ing node may be any communication unit capable of 
sending a data packet across a data network (such as 
the Internet), for example, awebserver,aPC, or a work- 
station running a web server such as www.yahoo.com, 
etc. The CN may also be any mobile data communica- 
tion unit such as a general packet radio system (GPRS) 
device or a 3 rd generation (3G) cellular phone, a per- 
sonal digital assistant (PDA), etc., connected to the data 
network through any type of access. 
[0053] Referring now to FIG. 6, a packet data routing 
mechanism 600 for mobile networks is illustrated; par- 
ticularly one supporting nested mobility, in accordance 
with the preferred embodiment of the present invention. 
A skilled artisan would recognise that the number of el- 
ements shown in the network of FIG. 6 are limited for 
clarity purposes only. 

[0054] The new mechanism provides route optimisa- 
tion, i.e. determining the shortest direct path for commu- 
nication between a MNN's Correspondent Nodes and 
this MNN. The preferred embodiments of the present 
invention find particular applicability in nested mobility 


scenarios (that is Mobile Networks visiting Mobile Net- 
works). The improvement is primarily achieved by add- 
ing intelligence to a Corresponding Node (CN) 655. 
[0055] The CN 655 in accordance with the preferred 
5 embodiment of the present invention has been adapted 
to include (i.e. at least generate, update and search) a 
new binding cache. The new binding cache is a linked 
binding cache 670 that provides pointers between 
cache addresses to improve data packet route optimi- 
ze sation. An adapted processor 605 that is operably cou- 
pled to the linked binding cache 670 performs the gen- 
eration, updating and searching of the linked binding 
cache 670. The processor is coupled to, or contains, a 
routing process 610, to generate data packet routes 
15 based on the pointers stored in the linked binding cache 
670. An interface 615 is provided on the CN 655 to fa- 
cilitate the improved delivery of data packets from CN 
655. The operation of the CN 655, processor 605, the 
routing process 610 and the linked binding cache 670 
are described in greater detail in the sections below. 
[0056] Adaptation of the CN 655 may be implemented 
by configuring or adapting any suitable element, for ex- 
ample processor 605. Alternatively, a new processor im- 
plementing processor-implementable instructions and/ 
or stored on a suitable storage medium, such as com- 
puter memory, hard disk, floppy disk, ROM, PROM etc, 
may be used to implement the processes described. 
The processor may, in some configuration, be a compu- 
ter, a network of computers, or one or more dedicated 
processors. 

[0057] More particularly, in the case of those per- 
formed by the CN, a memory element (not shown) other 
than the binding cache 670, for storing data or process- 
es used in the delivery of data packets may be adapted. 
[0058] Notably, the scenario in FIG. 6 illustrates how 
the mechanism described with relation to FIG. 4 may be 
extended and improved to provide an adequate solution 
in nested mobility situations. 

[0059] As described above with reference to FIG. 4, 
when CN2 255 has to send a packet to LFN2 1 65, CN2 
255 reviews its binding cache and finds the entry that 
the MR2 260 prefix is reachable at the MR2 care-of-ad- 
dress 520, 524. Hence, for all data packets being sent 
to LFN2 1 65, CN2 255 sends the data packet to MR2's 
care-of address that will intercepted by HA1 240, the 
home agent of MR1 150. 

[0060] The inventors of the present invention propose 
to extend the above technique by incorporating intelli- 
gence in the CN. In this regard, as shown in FIG. 6, when 
the CN 655 is about to send a data packet to any mobile 
node (MN) or fixed node, for example LFN 1 65, CN 655 
reviews its binding cache following a defined pattern. In 
the known technique, the CN (CN2 255) reviews its 
binding cache and finds the MR entry (i.e. the MR2 260 
prefix is reachable at the MR2 care-of-address 520, 
524) and stops at this point. In contrast to the known 
technique, when a registered intermediate address (i.e. 
a care-of-address) has been found for MN (or MN prefix 
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if MN is behind a mobile router), this care-of-address is 
again searched in the binding cache. If the care-of-ad- 
dress is covered by a prefix for which a BU has been 
received, the corresponding new care-of-address is 
searched and so on. Meanwhile, the routing header of 
the outbound packet is constructed so that it includes 
all (care-of/intermediate) addresses that have been suc- 
cessively found within the binding cache 670. The con- 
struction of the routing header is shown in greater detail 
in FIG. 11. 

[0061] Inthis manner, the full route forthe data packet 
can be determined by improved extraction and utilisa- 
tion of data within the improved binding cache. 
[0062] If we consider the example depicted in FIG. 6 
the following process would occur when a data packet 
is to be sent from CN 655 to LFNn 665. CN 655 searches 
its linked BC 670 entries for LFNn address. If the LFNn 
address is based on MR2 prefix (that is, LFNn address 
and MR2 prefix first 'MR2 prefix length 1 bits are identi- 
cal), the MR2 care-of-address is returned. The CN 655 
then searches its linked BC 670 entries for the MR2 
care-of address, which is based on the MR1 prefix (that 
is: MR2 care-of-address and MR1 prefix first 'MR1 prefix 
length' bits are identical). Thus, the MR1 care-of-ad- 
dress is returned. The CN 655 then searches its linked 
BC 670 entries for the MR1 care-of address. Notably, 
nothing is returned. Therefore, the linked binding cache 
search ends, and the CN 655 has knowledge of the op- 
timum route to be used forthe data packet to reach the 
intended recipient. 

[0063] Thus, CN 655 knows that the data packet has 
to be sent first to MR1 150, at MR1's care-of-address. 
CN 655 also knows that once MR1 1 50 forwards the da- 
ta packet to MR2 155, MR2 1 55 is able to pass the data 
packetto its intended recipient LFN 665. Note that these 
further hops have been stored in memory (either cache 
or an alternative memory) in order to build the Routing 
Header for that (and any subsequent) data packetto be 
sent to LFN 665, as described further below. 
[0064] The process shown in FIG. 6 illustrates a prac- 
tical scenario, where many nested levels may exist. 
Hence, the aforementioned process may be easily gen- 
eralized to an example of nested mobility involving n 
successive levels (n mobile routers MR^ MR n and n 
corresponding home agents HA 1f HAjJ . In this re- 
gard, let us assume that a local fixed node LFN is at- 
tached to MR n and the LFN is communicating with a cor- 
responding node CN. 

[0065] In the following description, the following no- 
menclature is used: 

A ' represents a tunnelled packet, - 

whereas 

A represents a "normai" packet, possibly con- 
taining a Routing Header. 

[0066] A first data packet CN-*LFN is sent through in 
the following manner: 


CN -> HA n -> ... HA 1 -> MR! -> ... -> MR n -> 

LFN. 

[0067] Notably, MR n de-tunnels the packet from HA n 
and sends a prefix scope BU to CN 655, informing CN 
5 655 that MR n prefix is reachable at MR n care-of ad- 
dress. 

[0068] Subsequently, a next packet CN->LFN is sent 
through in the following manner: 

CN -> HA^ -> HA 1 -> MR 1 -» ... + MR^ -» 

10 MR n -» LFN. 

[0069] MR n _., de-tunnels the packet from HA rv1 and 
sends a prefix scope BU to CN 655 informing CN 655 
that the MR n .-, prefix is reachable at the MR^ care-of 
address. On receipt of the BU, the CN 655 recognises 

15 that the packet has been sent to link n-1 (and then in- 
tercepted by HA,^) , as the CN 655 knows that the LFN 
is contactable by MR n link and that MR n is currently at 
MR n care-of address, which is coupled to link n-1 . 
[0070] Subsequently, a next data packet to be sent 

20 from the CN 655 to the LFN leads to the following CN 
operation. The LFN matches with the MR n prefix, so the 
MR n care-of-address is returned. The MR n care-of-ad- 
dress matches with MR n .., prefix, so the MR n _., care-of- 
address is returned. Notably, theMR^ care-of-address 

25 does not match with any prefix (MR n _ 2 binding update 
has not been received yet). Thus, the packet is sent 
through in the following manner: 

CN -> HA^ ->... ^HA 1 -> MR 1 -> MR n _ 2 -> 
MR n -l MR n -» LFN. 

30 [0071] Since it receives a tunnelled packet, MR n _ 2 
sends a prefix scope binding update to CN 655. 
[0072] Ultimately, the next packets lead to the CN op- 
erating in the following manner. The LFN address 
matches with MR n prefix. Hence, the MR n care-of-ad- 

35 dress is returned. The MR n care-of-address matches 
with MR^ prefix. Hence, the MR^ care-of-address is 
returned. Following the same principle through the nest- 
ed mobility network, the MR 3 care-of-address matches 
with the MR2 prefix. Hence, the MR 2 care-of-address is 

40 returned. Notably, the MR 2 care-of-address does not 
match with any prefix, as MR 1 BU has not been received 
yet. Thus, the packet is sent through in the following 
manner: 

CN HA 1 -> MR 1 -> MR 2 -> ... -> MR n -> LFN. 

45 [0073] Since it receives a tunnelled packet, M R.j then 
sends a prefix scope binding update to CN 655. 
[0074] The CN 655 then has a complete route 
mapped out for sending data packets to LFN. Hence, 
when the next packet is to be sent, the CN 655 operates 

so inthefollowingmanner.TheLFNmatcheswith MR n pre- 
fix. Hence, the MR n care-of-address is returned. The 
MR n care-of-address matches with MR rh1 prefix. Hence, 
the MR n _ 1 care-of-address is returned. And so on, until 
the MR 2 care-of-address matches with MR 1 prefix. 

55 Hence, the MR-j care-of-address is returned. The MR 1 
care-of-address does not match with any prefix (which 
is to be expected, as the MR1 is not visiting a mobile 
router). Thus, the data packet is sent through in the fol- 
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lowing manner: 

CN -> MR-j -> MR 2 -» ... -> MR n -> LFN. 
[0075] Notably, the data packet is sent through with 
the minimum of de-tunnelling operations, thereby 
achieving idea! route optimisation. 
[0076] Advantageously, no restriction is placed on the 
sender of the data packet or the intended recipient. 
Hence, the preferred embodiments apply in the same 
manner, whether the sender or intended recipient is ei- 
ther fixed or mobile, for example, the sender may be a 
fixed CN or a Mobile Node (MN), and the intended re- 
cipient may be a Mobile Network or a fixed node (i.e. 
LFN) or a mobile node at home in the Mobile Network 
(i.e. LMN) or a Mobile Node visiting a Mobile Network 
(i.e. VMN). 

[0077] Furthermore, in the preferred embodiment of 
the present invention, the search in the Linked Binding 
Cache does not stop after an initial entry has been 
found. On the contrary, the search continues until the 
returned care-of-address fails to match with any mobile 
router prefix for the first 'MR prefix length' bits of the ad- 
dress being searched. 

[0078] In accordance with the preferred embodiment 
of the present invention, a new method of building a 
Routing Header for outbound packets has been de- 
scribed, as above. 

[0079] Using the generated routing header, as ex- 
plained in the previous section, after reception of the 
Binding Updates from all intermediate MRs, the packets 
are sent through in the following manner: 

CN -> MR 1 -> MR 2 -> ... -> MR n -> LFN. 
[0080] This efficient routing operation is achieved 
through the recovery of all intermediate MR care-of ad- 
dresses, whilst determining the last MR (the care-of-ad- 
dress to which the packet has to be sent) in the se- 
quence. In this example, once the binding cache infor- 
mation has been generated as above, the MR n care-of- 
address is searched in the Linked Binding Cache. It is 
then found that the MR n care-of-address matches with 
MR rv1 prefix. Thus, MR n _.| care-of-address is searched 
for. However, notably, the MR n care-of-address is not 
lost or discarded, but is added to the routing header, in 
accordance with the preferred embodiment of the 
present invention. 

[0081] Hence, the routing header is dynamically con- 
structed. In the first packets sent (before any Binding 
Update is received), there is no routing header and the 
destination address is the LFN address. In the packets 
to be sent after reception of Binding Update from MRn, 
the routing header consists of the LFNn address and the 
data packets are sent to the MR n care-of address. Sub- 
sequent data packets to be sent are addressed as will 
be understood from the aforementioned description. In 
the last data packets, sent after reception of a Binding 
Update from the last intermediate MR (i.e. MR1), the 
routing header consists of the following: {MR 2 care-of 
address, MR 3 care-of address, MR n care-of address, 
LFNn address}. The data packets are then sent to the 
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MR 1 care-of address. 

[0082] The mechanisms described above for deter- 
mining the destination address and building the Routing 
Header for CN outbound packets achieves route optimi- 

5 sation for data packets addressed to LFN in n steps, 
where the 1 * packets are sent without any optimisation, 
and the last packets are sent with full optimisation (once 
the n Binding Updates from the n intermediate MRs 
have been received one after the other by CN). The full 

10 route optimisation is achieved in incremental steps 
since a Binding Update from an intermediate MR (e.g. 
MRn-i) will be received by the CN only once the Binding 
Update from the lower MR (i.e. MRn-i+1) has been re- 
ceived. This is due to the fact that MRs send their first 

15 Binding Update to CN only once they received a data 
packet from CN that has been encapsulated by their 
own HA. This implies that in the best case, full route op- 
timisation is only achieved for the (n+1) * packet sent 
by CN to LFN, where the n previous packets have con- 

20 secutively triggered the emission of Binding Updates 
from the n intermediate MRs in the following order (MRn, 
MRn-1,...,MR2, MR1). 

[0083] In accordance with an enhanced embodiment 
of the present invention, a method of determining a des- 
25 tination address and building a routing header in a single 
step is described. Thus, in summary in the enhanced 
embodiment, route optimisation may be achieved in a 
single step as follows: 

30 A 1 st packet is sent without any optimisation, and 
A 2 nd packet and all the subsequent packets are 
sent with full optimisation, that is CN^MR-j-*... 
MR n ->LFN. 

35 [0084] This enhancement to obtain route optimisation 
in a single step is based on extensive MR de-tunnelling. 
In summary, route optimisation was obtained in n steps 
in the above example because MR n is the only MR to 
send a BU to CN in the first step. Similarly, MR^ is the 

40 only MR to send a BU to CN in the second step (data 
packet sent after BU from MRn has been received), and 
so on. The inventors of the present invention have rec- 
ognised that route optimisation may be achieved in a 
single step if all MRs send a BU to the CN in the first 

^5 step, with a modified de-tunnelling technique. 

[0085] Such a modified techniq ue extends the known 
art, as described in the Thierry Ernst proposal, in: IETF 
Internet-Draft draft-emst-mobileip-v6-network-02.txt, 
June 2001. Here, it is specified that a Mobile Router 

so must send a BU "to the source address of the inner pack- 
et" when receiving a tunnelling packet from its Home 
Agent. That inner packet may very well be itself a tun- 
nelling packet. In this context, the MR does not inspect 
the content of the data packet. 

55 [0086] Therefore, the inventors propose that, in order 
to achieve route optimisation in a single step, the MR 
has to send a binding update to the source address con- 
tained in the /nne/ynosf-tunnelled packet. That inner- 
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most tunnelled packet is the packet that Is not Itself a 
tunnelling packet. Note however that each of the nested 
MRs must only de-tunnel one level (partially de-tunnel) 
before forwarding the packet; de-tunnelling the whole 
packet is done internally only for obtaining the BU des- 
tination. 

[0087] As described above, a key feature of the 
present invention is the increased intelligence in the CN, 
coupled to the new processes in building and using the 
CN's linked binding cache. 

[0088] Existing binding caches, as shown in FIG. 5, 
can be viewed as a list of two-element lists. Here, each 
entry consists of a home address (+ possibly the prefix 
length in case of a prefix entry) and the corresponding 
care-of address. 

[0089] The inventors of the present invention have al- 
so proposed an improved mechanism for building a 
linked binding cache. The method described above re- 
quires the CN to run through its binding cache 'n' times, 
in the case of nested mobility involving 'n' levels of mo- 
bile routers, in order to build the linked binding cache. 
[0090] However, in accordance with the preferred em- 
bodiment of the present invention, it is proposed that the 
linked binding cache is built by adding direct pointers 
from an entry A to another entry B, when the care-of- 
address of entry A fits into the range defined for the other 
entry B prefix. It is envisaged that the processor 605 
would build the linked binding cache 670, using the MR 
care-of-address information received through interface 
615 and processed by processor 605. 
[0091] Forthe simple network scenario shown in FIG. 
4, whereby LFN is reached via a first MR (MR1 ) 1 50 and 
a second MR (MR2) 260, the entry of MR2260 has been 
adapted to reference (direct pointer) the entry of MR1 
150. This linked binding cache arrangement 670 is illus- 
trated in FIG. 7. As before a binding cache address com- 
prises a list of addresses, specific to each MR in a nest- 
ed mobility scenario. The binding cache entries may in- 
clude, for example, a MR2 prefix and prefix length 520, 
with a link 522 (internal to each entry) to a determined 
MR2 care-of-address 524, if one has been determined. 
The MR2 entry 525 is linked 526 to the next entry in the 
binding cache, namely that f or MR1. The MR1 prefix and 
prefix length 510, includes a link 512 to a determined 
MR1 care-of-address 514, if one has been determined. 
A similar arrangement and link may be performed to 
MR3, and so on. 

[0092] In accordance with the preferred embodiment 
of the present invention, the linked binding cache 700 
has been identified as individual entries for each MR, 
namely MR1 entry 515 and MR2 entry 525. This reflects 
the entry link between the prefix and prefix length to any 
care-of-address that has been identified for that MR. 
The binding cache has been adapted to include a point- 
er 720 between the respective MR entry, for example 
M R2 entry 525 and the MR1 entry 515, thereby creating 
a linked binding cache 670. 

[0093] It is within the contemplation of the present in- 


vention that such a pointer 720 may be effected between 
the source entry and the care-of-address of the pointed 
entry, or from the source entry to the MR prefix and prefix 
length (51 0) of the pointed entry. 

5 [0094] The above methodology can be extended to 
the case of an n-level nested mobility, as shown in FIG. 
8. For a generic n-level nested mobility network scenar- 
io, the linked binding cache arrangement 800 includes 
'n' individual BC entries 51 5, 525 ... 860, 850. As before 

10 in FIG. 7, each BC entry includes fields relating to the 
MR prefix and prefix length, with the associated care- 
of-address, if known, specific to each MR. 
[0095] The binding cache entries may include, for ex- 
ample, a MR2 prefix and prefix length 520, with a link 

is 522 to a determined MR2 care-of-address 524, if one 
has been determined. The MR2 entry 525 is linked 526 
to the next entry in the binding cache, namely that for 
MR1 . The MR1 prefix and prefix length 510, includes a 
link 512 to a determined MR1 care-of-address 514, if 

20 one has been determined. This arrangement and asso- 
ciated links are translated to the MRn-1 and MRn links 
as shown in FIG. 8. 

[0096] In accordance with the preferred embodiment 
of the present invention, the binding cache 800 has been 

25 adapted to include links 720, 870, 840 between the re- 
spective MR entry and the other entries it points to, 
thereby creating a generic linked binding cache. A direct 
pointer is added from an entry A to an entry B if and only 
if entry B prefix matches with the 'entry B Prefix Length' 

so first bits of entry A care-of address. In FIG .8, the pointer 
840 has been included since MRn-1 prefix matches with 
the 'MRn-1 Prefix Length' first bits of MRn care-of ad- 
dress, and so on. 

[0097] Advantageously, the creation and use of this 
35 linked binding cache (i.e. binding cache extended with 
the direct pointers as described above) requires minor 
modifications to existing binding caches and associated 
searching algorithms. In this regard, the respective MR 
care-of-addresses are highlighted as being linked to en- 
40 tries whose prefix match the care-of addresses. This is 
_ achieved [ in the. routing process, by routing process 
function 610. Furthermore, by implementing the inven- 
tive concepts described herein, a CN is no longer limited 
to determining a single care-of-address, based on a de- 
45 termination of the initial routing MR - particularly in the 
case of nested network mobility. The routing process 
610 in the CN is able to map the whole route, through 
successive MRs, that a data packet would need to take 
to reach its intended recipient. In this manner, route op- 
50 timisation of the data packet can be achieved. 

[0098] In summary, the linked binding cache effective- 
ly generates a data route for the data packet to be sent, 
in contrast to existing binding caches that identify a sin- 
gle address (including prefix, prefix length and a single 
55 care-of-address, if known). 

[0099] Referring now to FIG. 9, a flowchart 900 illus- 
trates the preferred method of searching through a bind- 
ing cache, in accordance with the preferred embodiment 


9 


17 


EP 1 367 780 A1 


18 


of the present invention. The method is performed at the 
CN, and starts at step 91 0. 

[0100] Once a CN receives a request to send a data 
packet to a destination address, in step 920, the CN 
searches for that destination address in its binding 
cache. If the destination is found in step 940, the ad- 
dress is added to the routing header, as shown in step 
950. The care-of-address of the 'found' destination ad- 
dress is then used to replace, in step 960, the destina- 
tion address to be searched in step 930. 
[0101] Note that the aforementioned search method 
in the BC is general, and may apply even if the advanced 
pointer concept is not implemented. In that case, recur- 
sive parsing of the BC is performed for each care-of ad- 
dress found. 

[0102] Once no destination address can be found in 
step 940, the data packet is sent, in step 970. 
[01 03] I n the preferred embodiment of the present in- 
vention, recursive steps 930, 940, 950 and 960 in FIG. 
9, that of searching for a list of care-of addresses in the 
binding cache, will preferably use a linked binding 
cache, as described with reference to FIG. 7 and FIG. 
8. This will improve efficiency since the list of care-of 
addresses forming the optimal route to a destination can 
be found in a single step, with a so-calted linked binding 
cache; as opposed to a non-linked binding caches 
where recursive parsing is then required. 
[0104] Referring now to FIG. 1 0, a flowchart 1 000 il- 
lustrates a method for building a linked binding cache, 
in accordance with the preferred embodiment of the 
present invention. The CN builds the linked binding 
cache based on binding update messages received 
from a number of MRs. 

[0105] The process starts in step 1002, with the CN 
receiving a new binding cache (BC) entry from a MR in 
step 1 004, which is any BC entry that has been received 
in a Binding Update. That is, the entry may be a com- 
pletely new entry, or an update (new Co@, same Home 
Prefix (HP)) of an existing entry. The CN then starts a 
process of reviewing all BC entries, in step 1006, to de- 
termine any pointers between the new BC entry for that 
MR and any previously stored BC entries. 
[0106] The process of reviewing all BC entries to de- 
termine any pointers between the new BC entry for that 
MR and any previously stored BC entry starts with the 
first BC entry in the linked binding cache. Making the 
current BC entry the first BC entry in the linked binding 
cache, as in step 1008, can readily do this. In addition, 
the preferred embodiment of the present invention uses 
two flags: (i) a Test_Up_FIag, and (ii) a 
Test_Down_Flag, which are both set to a true' status. 
The Test_Up_Flag is used to indicate whether to test if 
a current BC Entry points to "New BC Entry" or not. The 
Test_Down_F!ag indicates whether to test if a current 
BC Entry has to be pointed to by "New BC Entry" or not. 
[0107] The home prefix (HP) of the current BC entry 
is then compared to the home prefix of the new BC entry 
for that MR, as shown in step 1010. Basically, if this de- 


termination is true, it identifies a "New BC Entry" as an 
update of an existing entry (since a single HP cannot 
have more than one Co@). Furthermore, if this test is 
true, then the "Current BC Entry" has been found that 

5 the entry "New BC Entry" has to update. 

[01 08] With regard to the use of flags, if the home pre- 
fix of the current BC entry matches the home prefix of 
the new BC entry for that MR, in step 1010, the 
TestJJp_Flag is set to a false' status, in step 1 012. The 

10 care-of-address of the current BC entry is set to equal 
the new BC entry in step 1014. 

[0109] Additionally, the pointer associated with the 
current BC entry is set to equal the pointer of the new 
BC entry, also in step 1014. This feature is important 
15 point as it erases a possible pointer from the 'Current 
BC Entry', which is no longer valid since Co© has just 
changed, and replaces it with the pointer from the 'New 
BC Entry', if it exists. 

[0110] The new BC entry is then made equal to the 
20 current BC entry, in step 1 01 6, and the current BC entry 
moved to the next BC entry in the binding cache 1 036 
if the current BC entry is not the last entry in the Binding 
Cache 1 034. This is required because the data structure 
of the 'New BC Entry' is dropped at the end of the proc- 
25 ess, as it is only used as an update. 

[0111] A determination is then made again as to 
whetherthe home prefix of the current BC entry matches 
the home prefix of the new BC entry for that MR, in step 
1010. 

30 [0112] When there is no match, in step 1010, a deter- 
mination is made as to whether the Test_Up_Flag is a 
true' status, as in step 1020. If the TestJJp_Flag is a 
true' status, in step 1 020, a determination of whether 
the care-of-address of the current BC entry matches the 
35 home prefix of the new BC entry is made in step 1 022. 
If there is no match, the method moves to step 1026. If 
there is a match, in step 1022, then a pointer is added 
from the current BC entry to the new BC entry, in step 
1024. 

40 [0113] The method then moves to step 1026, where 
a determination is made as to whether the 
Test_Down_Flag is a true' status. If the 
Test_Down_Flag is a true' status, in step 1026, a deter- 
mination of whether the care-of-address of the new BC 
45 entry matches the home prefix of the current BC entry 
is made in step 1028. If there is no match, the method 
moves to step 1034. If there is a match, in step 1034, 
then a pointer is added from the new BC entry to the 
current BC entry, in step 1030. The Test_Down_Flag is 
50 then set to a 'false' status, as shown in step 1 032. 
[0114] A determination is made as to whether all of 
the BC entries have been checked, in step 1 034. When 
the end of BC has been reached, a determination is still 
made as to whether the 'New BC Entry' was actually 
55 new, or if it was an update. If all of the BC entries have 
not yet been checked within this 'pass', i.e. the current 
BC entry is not the last BC entry in step 1034, a deter- 
mination is made as to whether remaining entries in the 
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linked binding cache have to be considered or not 1 035. 
If both the Test_Up_Flag and Test_Down_Flag are set 
to false 1 , there is no need to consider the remaining en- 
tries in the linked binding cache: the linked binding 
cache has been updated 1042 and the process ends 5 
1044. If one of (or both) Test_Up_Flag and 
Test_Down Flag is not set to 'false' the remaining en- 
tries in the linked binding cache need to be considered. 
Hence, the current BC entry is moved on to the next BC 
entry in step 1 036. The process then moves to a deter- io 
mination of whether the home prefix of the current BC 
entry matches the home prefix of the new BC entry for 
that MR, in step 1010. 

[0115] Otherwise, a determination is made as to 
whether the TestJJp_Flag is a 'true* status, in step 1 038. '5 
If the TestJJp_Flag is a 'true' status, in step 1 038, then 
a new BC entry is added at the end of the BC, in step 
1040. This effectively means that the status has re- 
mained the same and that an entry to update has not 
been found whilst reviewing all BC entries. As a conse- 20 
quence, "New BC entry" has to be added at the end of 
the BC. 

[01 1 6] However, if the Test_Up_Flag is a false* status, 
in step 1 038, the 'New BC Entry' was an update. Hence, 
the same prefix was found. Once all of the BC entries 25 
have been checked, the linked binding cache for that 
MR has been generated, in step 1042 and the process 
ends, in step 1044. 

[0117] At the end of the process, either a New BC En- 
try will be added to the BC, or it will have updated an 30 
existing BC entry. In this manner, a linked binding cache 
can be generated for each and every new BC entry that 
is received by the CN. The linked binding cache can then 
be used in a much more efficient manner when data 
packets are to be sent through the network, as the route 35 
to each and every MNN, LFN can be quickly determined. 
[01 1 8] It is noted that step 1 035 is a preferred option, 
in order to minimise cost, CPU run-time, etc. of the up- 
date of the BC. In other embodiments the process may, 
for example, follow steps 1 034 to 1 036. 40 
[0119] Furthermore, it is noted that step 1 026jsjnere- .... 
ly a preferred option In order to minimise cost, CPU run- 
time, etc. of the update of the BC. In other embodiments 
the process may, for example, follow steps 1020 to 
1028. 45 
[0120] Furthermore, the various steps described 
above need not necessarily be performed in the order 
they have been described. A skilled artisan would rec- 
ognise that an alternative order may be used, where 
benefit can still be gained in the route optimisation proc- so 
ess. For instance: the block formed with steps {1020, 
1022, and 1024} can be made after the block formed 
with steps {1026, 1028, 1030, and 1032}. 
[0121] Referring now to FIG. 11, the routing header 
1120 according to the preferred embodiment of the 55 
present invention is shown. This routing header is in- 
cluded in data packets sent by CN to an intended recip- 
ient (in a Mobile Network). As previously indicated, the 


20 

data packet 1100 includes a single IP header, incorpo- 
rating an IP source address (CN address) 1110, and an 
IP destination address of the first intermediate address 
(MR1 care-of-address) 1115. The data packet includes 
further the routing header 1120 filled with IP intermedi- 
ate addresses that form the route to the intended recip- 
ient, for example a LFN. Following the address informa- 
tion, the packet data (payload) is attached 1130. 
[0122] It Is within the contemplation of the invention 
that the aforementioned techniques of recursive parsing 
of a BC and/or use of an optimised linked binding cache 
may use any source routing mechanism. As such, the 
use of the routing header 1 1 20 is a preferred option only. 
An alternative mechanism of source routing is also illus- 
trated in FIG. 11. 

[0123] In this regard, a tunnelling operation is per- 
formed by the CN, when the CN wants to send a packet 
to an intended recipient (in a Mobile Network). The CN 
uses multiple encapsulations 1150 (i.e. multiple tunnel- 
ling operations) of the data packet to source route the 
packet to the destination. In this regard, the data packet 
1150 includes the first IP header, incorporating an IP 
source address (CN address) 1110, and an IP destina- 
tion address of the first intermediate address (M R1 care- 
of-address) 1115, as in the preferred routing header. 
However, each intermediate IP header will have the 
sender address as the source address 1110 and one of 
the 'n' consecutive IP intermediate addresses 1160, 
1170, etc., as the destination address. Finally, the orig- 
inal IP packet from the CN to the LFN will be included 
in the header, namely the addresses of the CN and LFN 
together with the packet data 1130. 
[0124] it is to be appreciated that the arrangement 
and specific details of interfaces, address types, routers 
etc. in the above embodiments are merely examples, 
and the invention is not limited to these examples. The 
invention should be viewed as capable of being applied 
to other aspects of the Internet or other types of data 
networks or protocols and subnets thereof. Further- 
more, the invention may also be applied to networks oth- 
.erthan the Internet, when such networks have subnets 
and access networks corresponding to those described 
above for the case of the Internet. 
[01 25] The invention, or at least embodiments there- 
of, tend to provide the following advantages, singly or in 
combination: 

(i) A data packet may be transmitted much more ef- 
ficiently, with a minimum of number of tunnelling op- 
erations performed by intermediary home agents, 
thereby achieving improved route optimisation. 

(ii) Route optimisation may be ascertained in a sin- 
gle step operation, based on extensive MR de-tun- 
nelling. 

(iii) An improved binding cache (a linked binding 
cache) can be created and used with minimal addi- 
tional processing or memory requirements. 

(iv) A solution for efficient data routing in IPv6, IPv4 
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or similar data network protocol has been achieved, 
particularly for systems supporting nested network 
mobility. 

[0126] Whilst the specific and preferred implementa- 
tions of the embodiments of the present invention are 
described above, it is clear that one skilled in the art 
could readily apply variations and modifications of such 
inventive concepts. 

[0127] Thus, a mechanism, apparatus and associat- 
ed methods to support route optimisation in Network 
mobility, especially in the case of IPv6, have been de- 
scribed, whereby the disadvantages associated with 
known mechanisms, apparatus and associated meth- 
ods have been substantially alleviated. In particular, a 
mechanism, apparatus and associated methods to sup- 
port route optimisation in the case of nested mobility, 
have been described. 


Claims 

1 . A method of transmitting at least one data packet 
(900) from a communication node in a data commu- 
nication network, the method comprising the steps 
of: 

receiving (920) a request at a communication 
node, to transmit said at least one data packet 
to a first destination address; 
searching (930) for said (first) destination ad- 
dress in a cache of the communication node; 
determining (940) an intermediary address of 
said destination address; the method charac- 
terised by the steps of: 

replacing (960) said destination address 
with said intermediary address to form a 
new destination address; 
repeating said steps of searching, deter- 
mining and replacing for said new destina- 
tion address(es), until no new intermediary 
address is found; and 
transmitting (970) said at least one data 
packet to said destination address via said 
intermediary address (es) 

2. The method of transmitting at least one data packet 
(900) from a communication node in a data commu- 
nication network according to Claim 1 , wherein said 
data communication network supports nested net- 
work mobility operation and said step of transmitting 
includes the step of: 

routing said at least one data packet via a plu- 
rality of routers in said nested mobility network. 

3. The method of transmitting at least one data packet 


(900) from a communication node in a data commu- 
nication network according to Claim 1 or Claim 2, 
wherein said data communication network operates 
in accordance with an IPv6 and/or IPv4 specif ica- 
5 tion. 

4. The method of transmitting at least one data packet 
(900) from a communication node in a data commu- 
nication network according to any preceding Claim, 

10 wherein the intermediary address(es) comprise a 
care-of-address for a previous address in a nested 
network. 

5. The method of transmitting at least one data packet 
is (900) from a communication node in a data commu- 
nication network according to any preceding Claim, 
wherein the communication node is a fixed corre- 
sponding node or a mobile node or the an intended 
recipient of the at least one data packet is a fixed 

20 node, for example a Local Fixed Node, or a Local 
Mobile Node or a Visiting Mobile Node. 

6. The method of transmitting at least one data packet 
(900) from a communication node in a data commu- 

25 nication network according to any preceding Claim, 
the method further characterised by the step of: 

adding (950) a plurality of said destination ad- 
dresses) and/or said intermediary address(es) 
30 to a routing header upon finding said destina- 

tion address or intermediary address(es), 
thereby providing a desired route for delivering 
said at least one data packet to an intended re- 
cipient. 

35 

7. The method of transmitting at least one data packet 
(900) from a communication node in a data commu- 
nication network according to Claim 6, wherein said 
step of adding includes adding a destination ad- 

40 dress of an intended recipient to said header; and 
adding one or more subsequent address (es) 
as subsequent routers acknowledge their presence 
in a route of said data packet. 

45 8. The method of transmitting at least one data packet 
(900) from a communication node in a data commu- 
nication network according to any of preceding 
Claims 1 to 5, the method further characterised by 
the step of: 

50 

adding (950) a plurality of IP headers contain- 
ing said intermediary address(es) to said at 
least one data packet upon finding said inter- 
mediary address(es), thereby providing a de- 
55 sired route for delivering said at least one data 

packet to an intended recipient. 

9. The method of transmitting at least one data packet 


12 


23 


EP 1 367 780 A1 


24 


(900) from a communication node in a data commu- 
nication network according to any of preceding 
Claims 5 to 8, wherein said step of adding includes 
determining an address of a final router to provide 
said intended recipient with said at least one data 
packet in order to complete a data route. 

10. The method of transmitting at least one data packet 
(900) from a communication node in a data commu- 
nication network according to any preceding Claim, 
the method further characterised by the steps of: 

de-tunnelling a portion of said at least one data 
packet at a router having an intermediary ad- 
dress, in order to determine an address of the 
communication node; and 
transmitting said intermediary address to said 
communication node. 

11. A method of generating a routing header (1100, 
1150) for transmitting a number of data packets 
from a communication node to an intended recipient 
over a data communication network that supports 
nested network mobility operation, the method 
comprising the step of: 

transmitting (970) a first data packet to a desti- 
nation address of said intended recipient via a 
plurality of routers in said nested mobility net- 
work, each router identified by an intermediary 
address; the method characterised by the 
steps of: 

de-tunnelling at least a portion of said at 
least one data packet at a number of rout- 
ers, in order to determine an address of the 
communication node; 
transmitting respective intermediary ad- 
dresses from respective routers, operating 
in a data path of said first data packet, to 
■. said communication node; and „ 

generating a routing header of a subse- 
quent second data packet, at said commu- 
nication node, for transmission of the sec- 
ond data packet to the intended recipient 
based on said respective intermediary ad- 
dresses. 

12. The method of generating a routing header accord- 
ing to Claim 11 , wherein the steps of de-tunnelling 
and transmitting intermediary addresses are per- 
formed by substantially all of the mobile routers in 
the data path of said first data packet, thereby gen- 
erating a substantially optimum route of the routing 
header for subsequent data packets transmitted to 
said intended recipient. 

13. The method of generating a routing header accord- 


ing to Claim 11 , wherein the steps of de-tunnelling 
and transmitting intermediary addresses are per- 
formed upon successive transmissions of data 
packets to said intended recipient by a successive 
5 one respective router in the data path. 

14. The method of generating a routing header accord- 
ing to any of preceding Claims 1 1 to 1 3, the method 
further characterised by the step of: 

10 

storing each intermediary address in a data 
path to said intended recipient in a linked bind- 
ing cache within the communication node, so 
that a substantially optimum data route via said 
15 addresses can be extracted from said linked 

binding cache in one pass for subsequently 
transmitted data packets. 

15. A communication message having a routing header 
20 generated in accordance with any of preceding 

Claims 11 to 14. 

16. A communication message having a routing header 
(1100, 1150) and a data packet (1130), the routing 

25 header comprising: 

an intended recipient address (1 1 80) of the da- 
ta packet; 

30 the communication message characterised by: 

a plurality of intermediary addresses (1115, 
1120, 1160, 1170) corresponding to a respec- 
tive plurality of mobile routers to be used to for- 
35 ward said data packet to said intended recipi- 

ent. 

17. The communication message according to Claim 
1 6, the communication message further character- 

40 ised by the plurality of intermediary addresses 
(1115, 1160, 1170) being configured as respective . 
IP headers where substantially each contains a 
sender address (1110) as a source address of the 
communication message and one of said plurality 

45 of intermediary addresses as a destination address 
(1160, 1170). 

18. A communication unit, for example a Correspond- 
ing Node (655), having: 

50 

a memory element storing a linked binding 
cache; and 

a processor, operably coupled to the memory 
element, for generating a routing process, 
55 based on information stored in the linked bind- 

ing cache, for delivering a data packet to an in- 
tended recipient. 
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19. The communication unit (655) according to Claim 
18, wherein linked binding cache includes pointers 
from one entry to the other when the care-of-ad- 
dress of an entry fits into the range defined for an- 
other's prefix. 

20. A communication unit, for example a Correspond- 
ing Node (655), having: a processor operabty cou- 
pled to a memory element storing a regular binding 
cache; wherein the communication unit is charac- 
terised by said processor employing a recursive 
approach of repeating said steps of searching, de- 
termining and replacing of new destination address 
(es) in the binding cache, in accordance with Claim 
1. 

21 . A method for building a linked binding cache (1 000), 
the method comprising the step of: 

storing a plurality of mobile router entries in a 
binding cache, wherein said plurality of mobile 
router entries include a first mobile router entry 
comprising a prefix and an indication of said 
prefix's length plus an associated intermediate 
address; and 

linking a second mobile router entry to said first 
mobile router entry for delivering at least one 
data packet via said first mobile router; the 
method characterised by the step of: 

adding (1 024, 1 030) a pointer in said bind- 
ing cache from the entry of said second 
mobile router to said first mobile router en- 
try when the intermediate address of said 
second mobile router matches the first mo- 
bile router's prefix in order to create a 
linked binding cache. 

22. The method for building a linked binding cache ac- 
cording to Claim 21 , the method further character- 
ised by the step of: 

receiving a binding update message from a 
number of mobile routers to indicate their re- 
spective intermediate address in delivering at 
least one data packet to an intended recipient. 

23. The method for building a linked binding cache ac- 
cording to any of preceding Claims 21 or Claim 22, 
the method further characterised by the steps of: 

receiving at least one tunnelled data packet at 
a third mobile router; 

de-tunnelling at least a portion of said at least 
one tunnelled data packet, by said third mobile 
router; and 

sending a binding update message to a com- 
munication unit indicating said third mobile 


router as an intermediate router for passing on 
a data packet to said intended recipient to en- 
able a pointer to be added in said linked binding 
cache from entry of said third mobile router to 
5 a second mobile router address. 

24. The method for building a linked binding cache ac- 
cording to any of preceding Claims 21 to 23, where- 
in the step of receiving, de-tunnelling and sending 
10 are performed by substantially each mobile router 
in a data path to the intended recipient, so that a 
linked binding cache for a data path route can be 
generated in a single step. 

15 25. The method for building a linked binding cache ac- 
cording to any of preceding Claims 21 to 24, the 
method further characterised by the step of: 

comparing an intermediate address of said sec- 
20 ond mobile router to a prefix address of sub- 

stantially each mobile router in said binding 
cache to determine whether a pointer should be 
added. 

25 26. The method for building a linked binding cache ac- 
cording to Claim 25, the method further character- 
ised by the step of: 

comparing, when a match in said comparison 
30 step is found, substantially all other intermedi- 

ate addresses to a prefix address of said sec- 
ond mobile router, to determine whether a 
pointer should be added to said second mobile 
router address; and 
35 repeating the comparison step process until no 

further match for an intermediate address is de- 
termined, thereby generating a preferred route 
to send at least one data packet to said recipi- 
ent. 

40 

27. A storage medium (665) storing processor-imple- 
mentable instructions for controlling a processor to 
carry out the method according to any of Claims 1 
to 10 or any of Claims 11 to 14 or any of Claims 21 

45 to 26. 

28. An apparatus adapted to perform the method ac- 
cording to any of Claims 1 to 1 0 or any of Claims 1 1 
to 14 or any of Claims 21 to 26. 

50 

29. A communication unit comprising apparatus ac- 
cording to Claim 28. 

30. A communication system comprising a communica- 
55 tion unit according to Claim 29 or apparatus accord- 
ing to Claim 28. 
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